跟着前OpenAI 大佬Karpathy学！用 LLM+Obsidian 搭建个人知识库，效率翻倍
目录
展开目录
工具安装
Obsidian
Claude Code
Claude Code网上安装教程很多，没有安装claude code的朋友，推荐这位大佬的方法Up: 人工大黑
如果不是claude官方订阅，推荐下一个cc switch来切换其他国产模型和api，非常好用！
Claudian
claudian是一个把claude code以图形化界面接入Obsidian的插件，比claude code原生的命令行界面好用很多
安装方法
在Obsidian设置里，先关闭安全模式，在第三方插件里搜索“brat”插件并安装
BRAT安装成功后启用插件，打开BRAT插件的设置页面，添加插件，输入claudian的地址进行安装：https://github.com/YishenTu/claudian
安装后就能在Obsidian的左边侧边栏看到一个小机器人按钮，这就是claudian了，点开就会有一个图形对话界面，背后就是claude code
Obsidian必备的5个skill
这是Obsidian CEO亲自做的5个skill，里面都是Obsidian的一些操作规范和最佳实践，也是非常好用，推荐安上
安装方式：直接把这个链接扔给你的claude code，让它安装上就行：https://github.com/kepano/obsidian-skills
搭建&使用教程
1.创建知识库文件夹结构
打开Obsidian新建一个仓库，直接把下面内容发给AI,AI会自动帮你创建好所有的文件夹以及对应的文件。
karpathy的wiki方法论（复制发给AI就可以）👇
# LLM Wiki
A pattern for building personal knowledge bases using LLMs.
This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.
## The core idea
Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.
The idea here is different. Instead of just retrieving from raw documents at query time, the LLM **incrementally builds and maintains a persistent wiki** — a structured, interlinked collection of markdown files that sits between you and the raw sources. When you add a new source, the LLM doesn't just index it for later retrieval. It reads it, extracts the key information, and integrates it into the existing wiki — updating entity pages, revising topic summaries, noting where new data contradicts old claims, strengthening or challenging the evolving synthesis. The knowledge is compiled once and then *kept current*, not re-derived on every query.
This is the key difference: **the wiki is a persistent, compounding artifact.** The cross-references are already there. The contradictions have already been flagged. The synthesis already reflects everything you've read. The wiki keeps getting richer with every source you add and every question you ask.
You never (or rarely) write the wiki yourself — the LLM writes and maintains all of it. You're in charge of sourcing, exploration, and asking the right questions. The LLM does all the grunt work — the summarizing, cross-referencing, filing, and bookkeeping that makes a knowledge base actually useful over time. In practice, I have the LLM agent open on one side and Obsidian open on the other. The LLM makes edits based on our conversation, and I browse the results in real time — following links, checking the graph view, reading the updated pages. Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.
This can apply to a lot of different contexts. A few examples:
- **Personal**: tracking your own goals, health, psychology, self-improvement — filing journal entries, articles, podcast notes, and building up a structured picture of yourself over time.
- **Research**: going deep on a topic over weeks or months — reading papers, articles, reports, and incrementally building a comprehensive wiki with an evolving thesis.
- **Reading a book**: filing each chapter as you go, building out pages for characters, themes, plot threads, and how they connect. By the end you have a rich companion wiki. Think of fan wikis like [Tolkien Gateway](https://tolkiengateway.net/wiki/Main_Page) — thousands of interlinked pages covering characters, places, events, languages, built by a community of volunteers over years. You could build something like that personally as you read, with the LLM doing all the cross-referencing and maintenance.
- **Business/team**: an internal wiki maintained by LLMs, fed by Slack threads, meeting transcripts, project documents, customer calls. Possibly with humans in the loop reviewing updates. The wiki stays current because the LLM does the maintenance that no one on the team wants to do.
- **Competitive analysis, due diligence, trip planning, course notes, hobby deep-dives** — anything where you're accumulating knowledge over time and want it organized rather than scattered.
## Architecture
There are three layers:
**Raw sources** — your curated collection of source documents. Articles, papers, images, data files. These are immutable — the LLM reads from them but never modifies them. This is your source of truth.
**The wiki** — a directory of LLM-generated markdown files. Summaries, entity pages, concept pages, comparisons, an overview, a synthesis. The LLM owns this layer entirely. It creates pages, updates them when new sources arrive, maintains cross-references, and keeps everything consistent. You read it; the LLM writes it.
**The schema** — a document (e.g. CLAUDE.md for Claude Code or AGENTS.md for Codex) that tells the LLM how the wiki is structured, what the conventions are, and what workflows to follow when ingesting sources, answering questions, or maintaining the wiki. This is the key configuration file — it's what makes the LLM a disciplined wiki maintainer rather than a generic chatbot. You and the LLM co-evolve this over time as you figure out what works for your domain.
## Operations
**Ingest.** You drop a new source into the raw collection and tell the LLM to process it. An example flow: the LLM reads the source, discusses key takeaways with you, writes a summary page in the wiki, updates the index, updates relevant entity and concept pages across the wiki, and appends an entry to the log. A single source might touch 10-15 wiki pages. Personally I prefer to ingest sources one at a time and stay involved — I read the summaries, check the updates, and guide the LLM on what to emphasize. But you could also batch-ingest many sources at once with less supervision. It's up to you to develop the workflow that fits your style and document it in the schema for future sessions.
**Query.** You ask questions against the wiki. The LLM searches for relevant pages, reads them, and synthesizes an answer with citations. Answers can take different forms depending on the question — a markdown page, a comparison table, a slide deck (Marp), a chart (matplotlib), a canvas. The important insight: **good answers can be filed back into the wiki as new pages.** A comparison you asked for, an analysis, a connection you discovered — these are valuable and shouldn't disappear into chat history. This way your explorations compound in the knowledge base just like ingested sources do.
**Lint.** Periodically, ask the LLM to health-check the wiki. Look for: contradictions between pages, stale claims that newer sources have superseded, orphan pages with no inbound links, important concepts mentioned but lacking their own page, missing cross-references, data gaps that could be filled with a web search. The LLM is good at suggesting new questions to investigate and new sources to look for. This keeps the wiki healthy as it grows.
## Indexing and logging
Two special files help the LLM (and you) navigate the wiki as it grows. They serve different purposes:
**index.md** is content-oriented. It's a catalog of everything in the wiki — each page listed with a link, a one-line summary, and optionally metadata like date or source count. Organized by category (entities, concepts, sources, etc.). The LLM updates it on every ingest. When answering a query, the LLM reads the index first to find relevant pages, then drills into them. This works surprisingly well at moderate scale (~100 sources, ~hundreds of pages) and avoids the need for embedding-based RAG infrastructure.
**log.md** is chronological. It's an append-only record of what happened and when — ingests, queries, lint passes. A useful tip: if each entry starts with a consistent prefix (e.g. `## [2026-04-02] ingest | Article Title`), the log becomes parseable with simple unix tools — `grep "^## \[" log.md | tail -5` gives you the last 5 entries. The log gives you a timeline of the wiki's evolution and helps the LLM understand what's been done recently.
## Optional: CLI tools
At some point you may want to build small tools that help the LLM operate on the wiki more efficiently. A search engine over the wiki pages is the most obvious one — at small scale the index file is enough, but as the wiki grows you want proper search. [qmd](https://github.com/tobi/qmd) is a good option: it's a local search engine for markdown files with hybrid BM25/vector search and LLM re-ranking, all on-device. It has both a CLI (so the LLM can shell out to it) and an MCP server (so the LLM can use it as a native tool). You could also build something simpler yourself — the LLM can help you vibe-code a naive search script as the need arises.
## Tips and tricks
- **Obsidian Web Clipper** is a browser extension that converts web articles to markdown. Very useful for quickly getting sources into your raw collection.
- **Download images locally.** In Obsidian Settings → Files and links, set "Attachment folder path" to a fixed directory (e.g. `raw/assets/`). Then in Settings → Hotkeys, search for "Download" to find "Download attachments for current file" and bind it to a hotkey (e.g. Ctrl+Shift+D). After clipping an article, hit the hotkey and all images get downloaded to local disk. This is optional but useful — it lets the LLM view and reference images directly instead of relying on URLs that may break. Note that LLMs can't natively read markdown with inline images in one pass — the workaround is to have the LLM read the text first, then view some or all of the referenced images separately to gain additional context. It's a bit clunky but works well enough.
- **Obsidian's graph view** is the best way to see the shape of your wiki — what's connected to what, which pages are hubs, which are orphans.
- **Marp** is a markdown-based slide deck format. Obsidian has a plugin for it. Useful for generating presentations directly from wiki content.
- **Dataview** is an Obsidian plugin that runs queries over page frontmatter. If your LLM adds YAML frontmatter to wiki pages (tags, dates, source counts), Dataview can generate dynamic tables and lists.
- The wiki is just a git repo of markdown files. You get version history, branching, and collaboration for free.
## Why this works
The tedious part of maintaining a knowledge base is not the reading or the thinking — it's the bookkeeping. Updating cross-references, keeping summaries current, noting when new data contradicts old claims, maintaining consistency across dozens of pages. Humans abandon wikis because the maintenance burden grows faster than the value. LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass. The wiki stays maintained because the cost of maintenance is near zero.
The human's job is to curate sources, direct the analysis, ask good questions, and think about what it all means. The LLM's job is everything else.
The idea is related in spirit to Vannevar Bush's Memex (1945) — a personal, curated knowledge store with associative trails between documents. Bush's vision was closer to this than to what the web became: private, actively curated, with the connections between documents as valuable as the documents themselves. The part he couldn't solve was who does the maintenance. The LLM handles that.
## Note
This document is intentionally abstract. It describes the idea, not a specific implementation. The exact directory structure, the schema conventions, the page formats, the tooling — all of that will depend on your domain, your preferences, and your LLM of choice. Everything mentioned above is optional and modular — pick what's useful, ignore what isn't. For example: your sources might be text-only, so you don't need image handling at all. Your wiki might be small enough that the index file is all you need, no search engine required. You might not care about slide decks and just want markdown pages. You might want a completely different set of output formats. The right way to use this is to share it with your LLM agent and work together to instantiate a version that fits your needs. The document's only job is to communicate the pattern. Your LLM can figure out the rest.
请你根据 karpathy 的这套方法，帮我把仓库里的文件夹的结构给建立起来
建立好后的文件结构大概长这样，可以根据你自己的需求来定制
如果你觉得AI给你创建的效果不好，也可以直接参考复制我的配置，
我的claude.md👇，直接复制内容替换掉你的claude.md内容，告诉AI按新的claude规则创建文件夹
## 文件夹结构
/
├── raw/ # 原始素材 (append-only, 永不修改)
│ ├── 笔记/ # 文章
│ ├── 资料/ # 播客/视频/音频转录
│ └── 图片/ # 论文/研究报告
├── wiki/ # 编译后的结构化知识 (AI 维护)
│ ├── 索引文件/ # 索引文件 (目录/标签索引)
│ ├── 整理笔记/ # 核心概念笔记
│ └── 主题摘要/ # 主题摘要
├── outputs/ # AI 生成输出
│ ├── 问答记录/ # 问答记录
│ └── 健康检查/ # 知识库健康检查报告
└── 指令.md # 本指令文件
## 工作流程
### 1️⃣ 收集 (Ingest)
- 将原始资料放入 `raw/` 下对应的子目录
- 格式：Markdown (.md) 为佳，也支持纯文本
- **规则**：一旦保存，永不修改（append-only）
### 2️⃣ 编译 (Compile)
- AI 定期读取 `raw/` 中的内容
- 提炼精华，写入 `wiki/` 下的结构化笔记
- 每篇 wiki 文件包含：
- 标题 + 一句话摘要
- 关键事实（要点列表）
- 关联知识链接 `[[wikilink]]`
- 原始来源引用
- 最后更新时间
### 3️⃣ 查询 (Query)
- 提问时，AI 先读取 `wiki/indexes/` 中的索引
- 找到相关概念笔记，综合回答
- 重要问答保存到 `outputs/qa/`
### 4️⃣ 健康检查 (Health Check)
- 定期检查 wiki 中的信息是否一致
- 标记矛盾、过时或无来源的内容
- 报告保存到 `outputs/health/`
## Wiki 编写规则
1. 每个文件以标题 + 一句摘要开头
2. 使用要点列表呈现关键事实
3. 使用 `[[wikilink]]` 关联相关知识
4. 末尾标注来源（引用 `raw/` 中的文件）
5. 末尾标注最后更新日期 `Last updated: YYYY-MM-DD`
6. 保持简洁，一页一个主题
## 知识库规则
- 原始资料在 `raw/` 中不可修改
- `wiki/` 由 AI 维护，人工可 review
- `outputs/` 是缓存，可随时清理/claude.md2.内容入库
推荐安装一个Obsidian官方的浏览器插件 Obsidian Web Clipper，在浏览器插件商店搜索安装。
这个插件可以一键以markdown格式保存网页内容、YouTube视频到Obsidian（带图片链接，图片支持下载到本地）
下面介绍如何设置将内容一键保存至指定仓库位置
设置好后，打开任意一个网页，点击插件，就能一键添加到提前指定好的位置
3.建立wiki概念
当你每新增一篇内容，就可以直接告诉AI，他会根据claude.md的指示自动帮你整理，建立wiki，自然对话就行
4.定期健康检查
当你内容多了之后，或者你想让AI检查一下wiki是否搭建完善，可以直接告诉AI，“做一轮健康检查”
5.将好的回答输出保存至wiki沉淀
当你觉得和AI讨论的内容很有价值时，可以直接让AI把这个回答保存至wiki，完成优质内容的沉淀&积累